The invention relates generally to processing of purchase card transactions and in particular to methods and systems for providing merchant services related to purchase card transaction processing.
A merchant who accepts purchase cards as payment for goods or services generally has an agreement with an acquiring bank for processing of purchase card transactions. As part of the agreement, the merchant maintains an account at the acquiring bank for deposit and withdrawal of funds associated with the merchant's purchase card transactions.
Purchase cards are issued to cardholders by a variety of card issuers, including banks, retailers, or other financial service providers. In the case of “interchange” cards, e.g., VISA or MASTERCARD card products, there is a card association that acts as an intermediary between the acquiring bank and the card issuer to complete a credit card transaction. (Rather than issuing cards itself, a card association generally licenses other entities to issue cards under its brand name.) In the case of “private label” credit cards, e.g., credit cards issued by a retailer, there is generally no intermediary; hence, such cards are generally accepted only by the issuing entity (or in some cases its subsidiaries).
A typical purchase-card sales transaction begins when a cardholder presents a purchase to a merchant in payment for goods or services. The merchant transmits an authorization request to its acquiring bank. In the case of interchange cards, the acquiring bank typically does not have direct access to information regarding cardholder account status, so the acquiring bank forwards the request to the appropriate card association for authorization.
If the transaction is authorized, an authorization code is returned to the merchant. The merchant completes the sales transaction with the cardholder by delivering the goods or services and obtaining in exchange a ticket representing the cardholder's agreement to pay the card issuer. The ticket is typically a piece of paper (usually signed by the cardholder) or an electronic equivalent. The ticket provides sufficient information to identify the cardholder, the card used, the merchant, and the amount of the transaction.
Next, the merchant collects payment for the transaction by presenting the ticket to the acquiring bank. Typically, the merchant accumulates tickets from a number of transactions (e.g., all transactions from one day) and presents a batch of tickets together to the acquiring bank. The acquiring bank acquires the ticket and deposits funds into the merchant's account. In general, the amount of funds deposited into the merchant's account is less than the amount of the sales transaction by a percentage (the “discount rate”) established between the merchant and the acquiring bank. The acquiring bank may also maintain a reserve against the merchant account by temporarily withholding part of the funds in order to cover the risk that the acquiring bank is not subsequently repaid by a card issuer for any of the merchant's transactions. Funds held in reserve are usually released to the merchant account after some period of time.
The acquiring bank presents the ticket to the card issuer for settlement. Settlement requests may be processed in batches and may be routed through a card association rather than being sent directly to the card issuer. The card issuer transfers funds to the acquiring bank in exchange for the ticket. The amount of funds transferred is, in general, less than the amount of the sales transaction because the card issuer deducts an “interchange fee” reflecting the delay between the card issuer's payment to the acquiring bank and the cardholder's payment to the card issuer, as well as any costs associated with use of a card association's interchange services. At some point after settlement, the card issuer bills the cardholder for the full amount of the transaction, and the cardholder pays the card issuer according to the terms of their agreement.
For a transaction where a private label credit card is used, the processing is similar, except that the acquiring bank and the card issuer are generally the same entity. Thus, the acquiring bank is able to authorize the transaction, and settlement between the card issuer and the acquiring bank is not required. As is generally known, acquisition and settlement processing may have many other variations, depending on the card product used and the card acceptance policies adopted by various card issuers and associations (e.g., some card associations settle directly with the merchant and do not transfer funds to the acquirer).
Acquiring banks are thus confronted with considerable complexity in managing purchase card operations, particularly when the bank provides card processing services for a large number of merchants who accept a variety of card products of different card associations and/or issuers. Transactions must be received and routed, and accounting of debits and credits of funds during acquisition and settlement must be maintained. Information for each merchant must be kept up-to-date. Periodic account statements and other activity reports must be generated and sent to each merchant. Further, an acquiring bank may outsource some or all of its merchant processing operations to a third-party provider of merchant processing services. These third-party providers confront an added level of complexity because of the need to manage data and transactions for multiple acquiring banks.
Existing systems generally rely on batch processing to perform all merchant processing functions, including monetary transactions (e.g., acquisition and settlement) and non-monetary transactions (e.g., opening and closing merchant accounts, changing merchant account terms, and updating merchant contact information). In batch processing, transaction requests are received by the acquiring bank or third-party merchant services provider and accumulated for periodic processing, e.g., once per day. Until the batch is processed, the transaction remains incomplete, and information related to the transaction is generally unavailable to merchants or acquiring banks. Moreover, any errors in the batch cannot be corrected until the next batch update cycle. Thus, batch processing limits the ability of acquiring banks or third-party providers to provide merchant processing services in real time; a merchant may have to wait a day or more for a desired change, such as the ability to accept a new type of credit card, to take effect.
Hence, it would be desirable to provide reliable and efficient merchant processing systems that can be used to manage merchant services more effectively.